UMTS (Universal Mobile Telecommunications System) is the 3G (3rd Generation) mobile communication system standardized by 3GPP (3rd Generation Partnership Project). The 3GPP launched a study item “Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”. The study investigates means of achieving major leaps in performance in order to improve service provisioning, and to reduce user and operator costs. in view of these studies and in order to enable interworking with other radio access technologies, the need arose for the definition of a new Evolved Packet Core (EPC) network. For further details, please see 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, version 8.3.0 and 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”, version 8.3.0, both documents available at http://www.3gpp.org and incorporated herein by reference.
An exemplary representation of the E-UTRAN architecture of LTE is shown in FIG. 1. In the following, the most important entities in this architecture are explained to facilitate a better understanding of the invention described herein.
The E-UTRAN consists of evolved Node Bs (eNBs or eNode Bs), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node. The eNodeB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers.
The eNode Bs are interconnected with each other by means of the X2 interface. The eNode Bs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (S-GW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNode Bs.
The Serving Gateway routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating the S4 interface and relaying the traffic between 2G/3G systems and PDN-GW). For idle state UEs, the Serving Gateway terminates the downlink data path and triggers paging when downlink data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the Serving Gateway for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for Non-Access Stratum (NAS) signaling and handles the security key management. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN (Serving GPRS Support Node). The MME also terminates the S6a interface towards the home HSS for roaming UEs.
The Packet Data Network Gateway (PDN-GW) provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one Packet Data Network Gateway for accessing multiple Packet Data Networks (PDNs). The Packet Data Network Gateway performs policy enforcement, packet filtering for each user, charging support, lawful Interception and packet screening. Another key role of the Packet Data Network Gateway is to act as the anchor for mobility between 3GPP and non-3GPP technologies.
To summarize the architecture depicted in FIG. 1, the new 3GPP Core Network is mainly separated into three logical entities in order to support the new E-UTRAN access. In the user plane, the Packet Data Network Gateway (PDN-GW) is the gateway to the external networks and the global mobility anchor for mobility between 3GPP and non-3GPP access technologies (for example, CDMA 2000, WiMAX or WIFI). Also in the user plane, the Serving Gateway can be considered the mobility anchor for mobility between 3GPP accesses (E-UTRAN, UTRAN, GERAN). The Mobility Management Entity (MME) is the control plane entity responsible for the mobility management of UEs (also referred to in the following as mobile nodes, mobile nodes or MNs) moving between different E-UTRAN base stations (eNode Bs) and for the session management.
Another aspect of LTE is the support of 3GPP accesses (e.g. GERAN, UTRAN, E-UTRAN), non-3GPP accesses (e.g. WLAN, WiMAX, 3GPP2, etc.) and mobility between those different types of access, i.e. in a heterogeneous network. The anchor for the mobility between the 3GPP and the non-3GPP accesses is a Packet Data Network Gateway that also provides the interface to the external Packet Data Networks. The mobility between 3GPP and non-3GPP accesses is based on Mobile IP—the protocol used can be either Client Mobile IP (see Johnson et al., “Mobility Support in IPv6”, IETF RFC 3775, June 2004 and Soliman et al., “Mobile IPv6 Support for Dual Stack Hosts and Routers”, IETF Internet Draft, draft-ietf-mext-nemo-v4traversal-06.txt, November 2008, both documents available at http://www.ietf.org and incorporated herein by reference) or Proxy Mobile IP (see Gundavelli et al., “Proxy Mobile IPv6”, IETF RFC 5213, August 2008 and Leung et al., “WIMAX Forum/3GPP2 Proxy Mobile IPv4”, IETF Internet Draft, draft-leung-mip4-proxy-mode-09.txt, July 2008, both documents available at http://www.ietf.org and incorporated herein by reference).
As described above, the mobility management entity (MME) is responsible for mobility management and session management. For each mobile node attached to an MME, specific mobility management and evolved packet system context information is stored in the MME. These contexts comprise, e.g. the mobility state, the temporary identity, the current Tracking Area List, last known cell, authentication vectors, access restrictions, subscribed QoS profile, subscribed charging characteristics, and for each active PDN connection the APN (Access Point Name) in use, IPv4/IPv6 addresses, PDN-GW address for control plane, and also information for each EPS (Evolved Packet System) bearer within the PDN connection, as for example EPS bearer QoS profile, EPS bearer charging characteristics.
The mobility management within the 3GPP system is network controlled, and two protocol variants are standardised for the interface between the PDN-GW and the Serving GW. One is based on GTP (GPRS Tunneling Protocol), the protocol used in the legacy GPRS (General Packet Radio Service) system, and the other one is Proxy Mobile IPv6 developed in the Internet Engineering Task Force (IETF)—see Gundavelli et al., “Proxy Mobile IPv6”, IETF RFC 5213, August 2008, available at http://www.ietf.org and being incorporated herein by reference. For interworking with non-3GPP access networks, the mobile node can be connected to the 3GPP core network, i.e. the PDN-GW, via PMIPv6 as well, in case the non-3GPP access supports PMIPv6. Alternatively, if the mobile node does not support inter-access handover with PMIPv6 or if the non-3GPP access does not support PMIPv6, the mobile node can be connected to the 3GPP core network via Client Mobile IP, e.g. Mobile IPv4 in Foreign Agent Mode. (see Perkins, “IP Mobility Support for IPv4”, IETF RFC 3344, August 2002, available at http://www.ietf.org and incorporated herein by reference) or Dual Stack Mobile IPv6 (DSMIPv6—see H. Soliman, “Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)”, IETF Internet Draft, draft-ietf-mip6-nemo-v4traversal-06.txt, November, 2007, available at http://www.ietf.org and incorporated herein by reference).
The non-3GPP accesses are separated into trusted accesses and untrusted accesses. The assumption for untrusted accesses is that a mobile node in an untrusted access needs first a secure tunnel (based on IPsec) to an evolved Packet data network gateway (ePDG) before being able to access operator services, i.e. the packet data network. The ePDG is similar to the PDG used for Interworking WLAN (as described in 3GPP TS 23.234, “3GPP system to Wireless Local Area Network (WLAN) interworking; System description”, version 7.7.0, August 2008, available at http://www.3gpp.org and incorporated herein by reference). For trusted accesses, a secure tunnel is not needed.
Before a mobile node can access a trusted or untrusted non-3GPP access network, access authentication is performed. If 3GPP based access authentication is applied in the non-3GPP access, i.e. the 3GPP AAA server/HSS authenticates the mobile node, EAP-AKA is used (see Arkko et at, “Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)”, IETF RFC 4187, August 2006, available at http://www.ietf.org and incorporated herein by reference).
When the mobile node is active in a non-3GPP access network, there a local IP address is used to route packets to the mobile node in the non-3GPP access. This IP address is the care-of address (CoA) using the terminology of Mobile IP (MIP). In case of DSMIPv6, the address is assigned to the mobile node, and the mobile node is sending binding updates using its care-of address to the PDN-GW, which has the function of the home agent (HA). In case of PMIPv6, the care-of address is an address of a mobile access gateway (MAG) that is located in the non-3GPP access network or in the ePDG, and the MAG is sending proxy binding updates using its (proxy-)care-of address to the PDN-GW of the 3GPP network, which has the function of the local mobility anchor (LMA).
For mobility within the same or between different non-3GPP accesses similar mechanisms can be used as for mobility between 3GPP and non-3GPP accesses, i.e. Client or Proxy Mobile IP.
As will be outlined in the following below, the setup of multiple sessions with connections to different packet data networks is time consuming due to the mobile node's home link detection. This will be explained in the following using the exemplary scenario shown in FIG. 2.
A mobile node attaches 2001 to a non-3GPP access and establishes 2002 a connection to a PDN 1 through a PDN-GW 201. During the attach procedure the mobile node receives 2003 a prefix 1 in the non-3GPP access that can be either a foreign prefix (advertised from an access router) or a home prefix (e.g. advertised from MAG 203). During the attach procedure the mobile node has not received any information whether the prefix is a foreign prefix or a home prefix, neither during access authentication nor with DHCP nor access specific procedures nor extensions of router advertisements. Therefore the mobile node performs home link detection, by DSMIPv6 bootstrapping with PDN-GW 201 (see G. Giaretta et al., “Mobile IPv6 Bootstrapping in Split Scenario”, IETF RFC 5026, October 2007, available at http://www.ietf.org and incorporated herein by reference). During bootstrapping the mobile node receives the home prefix assigned by PDN GW 201. The mobile node compares the prefix locally assigned in the non-3GPP access with the prefix received during bootstrapping.
After the connection to PDN 201 is established, the mobile node wants to set up an additional connection to a PDN 202 via a PDN-GW 2. According to the 3GPP Release 8 specification of 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses (Release 8)”, version 8.3.0, September 2008 (available at http://www.3gpp.org and incorporated herein by reference), a mobile node located in non-3GPP access network cannot be on a home link for one PDN connection and on a foreign link for another PDN connection. In this scenario, this restriction is not obeyed, i.e. the prefix advertised for one PDN connection can be a home prefix and the prefix advertised for another PDN connection can be a foreign prefix.
In this case, in order to establish the additional PDN connection, the mobile node can use the DSMIPv6 bootstrapping to bootstrap with PDN-GW 202. This is possible because the mobile node already has at least one IP address from the PDN connection to PDN 1. Therefore, the address used as local IP address for DSM1Pv6 bootstrapping with the PDN-GW 202 can be either a foreign IP address from the non-3GPP access, which is also used as CoA for the PDN-GW 201 connection, for example, if the UE is not on home link for the PDN 1 connection, or the local IP address used for bootstrapping can be the home address (HoA) from the PDN-GW 201.
However, in both cases the local IP address can not be equal to the home address 2 assigned by PDN-GW 202, even in case home link would be possible in the non-3GPP access for the PDN-GW 2 connection (i.e, PMIP tunneling between non-3GPP access and PDN-GW is supported), because the local IP address is already assigned before the establishment of the connection to PDN-GW 202 is initiated and the home address 2 is allocated. The local IP address is used as care-of address, i.e. the mobile node sends a binding update to PDN-GW 202, and always DSMIPv6 with bi-directional tunneling is used (see FIG. 3). Therefore, the mechanism adds unnecessary overhead (IP-in-IP tunneling to PDN-GW 202).